With recent developments in memory systems, available addressable volatile memory, e.g., operative memory or random access memory (RAM), per server has increased enabling the storage of large volumes of data by data processing systems such as the In-memory Appliance. The In-memory appliance keeps the bulk of its data in volatile memory for maximum performance, but still uses persistent storage (non-volatile memory) to provide a fallback in case of failure. During normal operation of the database, data is automatically saved from memory to disk at regular savepoints.
However, performing a backup of databases that are stored in main memory would require taking a full backup of the file system as well as the main memory over a span of certain time period. During this time, the system may not be used in parallel due to a drastic reduction in the system's performance. Further, working on the data being copied may result in inconsistent copy of data. In order to avoid this situation, typically, the work processes currently executed on the data being copied are interrupted partially or completely until the copy operation is completed. Alternative solutions include capturing all the data changes in a log and saving the log from main memory to persistent storage after each committed database transaction. The data can be recovered like any disk-based database, e.g., returned to its last consistent state by replaying the log since the last savepoint.